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Abstract 


Elastic signature (ES) aims to sign data with a human friendly secret. The secret will be 
verified fully on-chain and is not stored anywhere. A user can change the secret as 
often as they need to. The secret does not have a fixed length. The secret will be like 
a password, which is a better understood concept than private key. This is specifically 
true for non-technical users. This EIP defines a smart contract interface to verify and 
authorize operations with ES. 


Motivation 


What would a changeable “private key” enable us? For years, we have been looking 
for ways to lower on-boarding barrier for users, especially those with less technical 
experiences. Private key custody solutions seem to provide an user friendly on- 
boarding experience, but it is vendor dependent and is not decentralized. ES makes a 
breakthrough with Zero-knowledge technology. Users generate proof of knowing the 
secret and a smart contract will verify the proof. 
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Use case 


ES is an alternative signing algorithm. It is not an either-or solution to the private key. 
It is designed to serve as an additional signing mechanism on top of the private key 
signature. 


e A DeFi app can utilize ES into their transfer fund process. Users will be 
required to provide their passwords to complete the transaction. This gives 
an extra protection even if the private key is compromised. 

e ES can also be used as a plugin to a smart contract wallet, like Account 
Abstraction ERC-4337. A decentralized password is picked instead of the 
private key. This could lead to a smooth onboarding experiences for new 
Ethereum Dapp users. 


Specification 
Let: 


e pwdhash represents the hash of the private secret (password). 

e datahash represents the hash of an intended transaction data. 

e fullhash represents the hash of datahash and all the well-known variables. 
e expiration is the timestamp after which the intended transaction expires. 

e allhash represents the hash of fullhash and pwdhash . 


There are three parties involved, Verifier, Requester and Prover. 


e A verifier, 
o SHOULD compute fullhash froma datahash , which is provided by 
the requester. 
o SHOULD derive pwdhash for a given address. The address can be an 
EOA or a smart contract wallet. 
o SHOULD verify the proof with the derived pwdhash , the computed 
fullhash anda allhash , which is submitted by the requester. 
e A requester 
o SHOULD generate datahash and decide an expiration . 
o SHALL request a verification from the verifier with, 
= proof and allhash which are provided by the prover; 
= datahash ; 
= expiration. 
e A prover 
o SHOULD generate the proof and allhash from, 
= datahash and expiration which are agreed with the 
requester; 
= nonce and other well-known variables. 


There are also some requirements. 
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e well-known variable SHOULD be available to all parties. 
o SHOULD include a nonce. 
o SHOULD include a chainid . 
o MAY include any variable that is specific to the verifier. 
e public statements SHOULD include, 
o one reflecting the pwdhash ; 
o one reflecting the fullhash ; 
o one reflecting the allhash . 
e The computation of fullhash SHOULD be agreed by both the verifier and 
the prover. 
e The computation of datahash 


IElasticSignature Interface 


This is the verifier interface. 


pragma solidity *%0.8.0; 


interface IElasticSignature { 
/** 
* Event emitted after user set/reset their password 
* @param user - an user's address, for whom the password hash is set. It could 
* or an EOA wallet address. 
* @param pwdhash - a password hash 
A 


event SetPassword(address indexed user, uint indexed pwdhash); 


JEF 
* Event emitted after a successful verification performed for an user 
* @param user - an user's address, for whom the submitted “proof is verified. 
* address or an EOA wallet address. 
* @param nonce - a new nonce, which is newly generated to replace the Last usec 
*/ 


event Verified(address indexed user, uint indexed nonce); 


JEF 
* Get `pwdhash` for a user 
* @param user - a user's address 
* @return - the “pwdhash” for the given address 
*/ 


function pwdhashOf (address user) external view returns (uint); 


JEF 
* Update an user's `pwdhash` 
* @param proof1 - proof generated by the old password 
* @param expiration1 - old password signing expiry seconds 
* @param allhashi1 - allhash generated with the old password 
* @param proof2 - proof generated by the new password 
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* @param pwdhash2 - hash of the new password 
* @param expiration2 - new password signing expiry seconds 
* @param allhash2 - allhash generated with the new password 
oe 
function resetPassword( 
uint[8] memory proof1, 
uint expiration1, 
uint allhashi, 
uint[8] memory proof2, 
uint pwdhash2, 
uint expiration2, 
uint allhash2 
) external; 


JEF 
* Verify a proof for a given user 
* It should be invoked by other contracts. The other contracts provide the `dat 
* the user. 
* @param user - a user's address, for whom the verification will be carried ou 
* @param proof - a proof generated by the password 
* @param datahash - the data what user signing, this is the hash of the data 
* @param expiration - number of seconds from now, after which the proof is expi 
* @param allhash - public statement, generated along with the `proof` 
*/ 
function verify( 
address user, 
uint[8] memory proof, 
uint datahash, 
uint expiration, 
uint allhash 
) external; 


verify function SHOULD be called by another contract. The other contract SHOULD 
generate the datahash to call this. The function SHOULD verify if the allhash is 
computed correctly and honestly with the password. 


Rationale 


The contract will store everyone's pwdhash . 


https://eips.ethereum.org/EIPS/eip-6327 4/9 


2023/6/4 f%_£9:25 ERC-6327: Elastic Signature 


wallet address ( 
Oxd8dA6BF26964aF9D7eEd9e03E53415D37 —— pwdhash «— nL 
aA96045) ‘SS 


address proof 1 


e 
pwd pwdhash ~ 
expiration 
allhash 
wa (input } chainid 
— - 


nonce fullhash 
token 


amount datahash 


The chart below shows ZK circuit logic. 
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To verify the signature, it needs proof, allhash, pwdhash and fullhash . 


H datahash fullhash 
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User {t Third-party contract ppor ES contract proof 
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The prover generates proof along with the public outputs. They will send all of them 
to a third-party requester contract. The requester will generate the datahash . It sends 
datahash , proof, allhash, expiration and prover's address to the verifier contract. 
The contract verifies that the datahash is from the prover, which means the 

withdrawal operation is signed by the prover’s password. 
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Backwards Compatibility 


This EIP is backward compatible with previous work on signature validation since this 
method is specific to password based signatures and not EOA signatures. 


Reference Implementation 


Example implementation of a signing contract: 


pragma solidity ^0.8.0; 


import "../interfaces/IElasticSignature.sol"; 


import "./verifier.sol"; 
contract ZKPass is IElasticSignature { 
Verifier verifier = new Verifier(); 


mapping(address => uint) public pwdhashOf; 
mapping(address => uint) public nonceOf; 


constructor() { 


} 


function resetPassword( 
uint[8] memory proof1, 
uint expiration1, 
uint allhash1, 
uint[8] memory proof2, 
uint pwdhash2, 
uint expiration2, 
uint allhash2 
) public override { 
uint nonce = nonceOf[msg.sender ]; 


if (nonce == 0) { 


//init password 


pwdhashOf[msg.sender] = pwdhash2; 

nonceOf[msg.sender] = 1; 

verify(msg.sender, proof2, ©, expiration2, allhash2); 
} else { 

//reset password 


// check old pwdhash 
verify(msg.sender, proof1, ©, expiration1, allhash1); 


// check new pwdhash 
pwdhashOf[msg.sender] = pwdhash2; 
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verify(msg.sender, proof2, ©, expiration2, allhash2); 


emit SetPassword(msg.sender, pwdhash2); 


function verify( 
address user, 
uint[8] memory proof, 
uint datahash, 
uint expiration, 
uint allhash 
) public override { 
require( 
block.timestamp < expiration, 
"ZKPass::verify: expired" 


ys 


uint pwdhash = pwdhashOf[user]; 
require( 

pwdhash != @, 

"ZKPass::verify: user not exist" 


); 


uint nonce = nonceOf[user]; 
uint fullhash = uint(keccak256(abi.encodePacked(expiration, block.chainid, r 
require( 

verifyProof (proof, pwdhash, fullhash, allhash), 

"ZKPass::verify: verify proof fail" 


); 
nonceOf[user] = nonce + 1; 


emit Verified(user, nonce); 


VILIISII TAT util STITT TL LTT 


function verifyProof( 
uint[8] memory proof, 
uint pwdhash, 
uint fullhash, //254b 
uint allhash 
) internal view returns (bool) { 
return 
verifier. verifyProof ( 
[proof[@], proof[i]], 
[[proof[2], proof[3]], [proof[4], proof[5]]], 
[proof[6], proof[7]], 
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[pwdhash, fullhash, allhash] 
)3 


verifier.sol is auto generated by snarkjs, the source code circuit.circom is below 


pragma circom 2.0.0; 
include "../../node_modules/circomlib/circuits/poseidon.circom"; 
template Main() { 

Signal input in[3]; 


signal output out[3]; 


component poseidon1 = Poseidon(2); 
component poseidon2 = Poseidon(2); 


poseidoni.inputs[@] <== in[@]; //pwd 
poseidoni.inputs[1] <== in[1]; //address 
out[@] <== poseidon1.out; //pwdhash 
poseidon2.inputs[@] <== poseidon1.out; 
poseidon2.inputs[1] <== in[2]; //fullhash 
out[1] <== in[2]; //fulLlhash 

out[2] <== poseidon2.out; //alLhash 


component main = Main(); 


Security Considerations 


Since the pwdhash is public, it is possible to be crack the password. We estimate the 
Poseidon hash rate of RTX3090 would be 100Mhash/s, this is the estimate of crack 
time: 


8 chars (number) : 1 secs 

8 chars (number + english) : 25 days 

8 chars (number + english + symbol) : 594 days 
12 chars (number) : 10000 secs 

12 chars (number + english) : 1023042 years 


12 chars (number + english + symbol) : 116586246 years 
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The crack difficulty of private key is 2^256, the crack difficulty of 40 chars (number + 
english + symbol) is 9240, 92440 > 2256, so when password is 40 chars , it is more 
difficult to be crack than private key. 
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